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Abstract —  The  successful  design  and  implementation  of  secure 
systems  must  occur  from  the  beginning.  A  component  that  must 
process  data  at  multiple  security  levels  is  very  critical  and 
must  go  through  additional  evaluation  to  ensure  the  processing 
is  secure.  It  is  common  practice  to  isolate  and  separate  the 
processing  of  data  at  different  levels  into  different  components.  In 
this  paper  we  present  architecture-based  refinement  techniques 
for  the  design  of  multi-level  secure  systems.  We  discuss  what 
security  requirements  must  be  satisfied  through  the  refinement 
process,  including  when  separation  works  and  when  it  does  not. 
The  process  oriented  approach  will  lead  to  verified  engineering 
techniques  for  secure  systems,  which  should  greatly  reduce  the 
cost  of  certification  of  those  systems. 

Keywords:  Architectural  Refinement,  Non-functional  require¬ 
ments,  computer  security. 

1.  Introduction 

In  recent  years,  security  has  been  a  growing  concern  in 
software  engineering  research,  especially  software  architecture 
research.  In  IEEE/ ANSI  830-1993,  security  is  defined  as  one 
of  the  thirteen  non-functional  (or  quality)  requirements  (NERs) 
that  must  be  included  in  the  software  requirements  document. 
Other  NERs  include  performance,  verification,  acceptance, 
portability,  reliability,  maintainability,  and  safety  [1].  NERs 
refer  to  the  whole  software  and  thus  cannot  be  presented 
in  software  architecture  as  components  or  functions  offered 
by  the  system  [2].  The  overall  software  architecture  and 
NERs  are  closely  related  and  should  be  studied  together 
during  architectural  development.  In  the  literature,  much  of  the 
research  focuses  on  how  to  satisfy  NERs  such  as  reliability  and 
performance  [1],  [3],  [4],  [5],  [6],  [7],  instead  of  security.  There 
has  been  some  work  on  security  architecture  modelling  [8], 
[9],  but  not  on  providing  security  architecture  design  guidance 
for  architects.  Banerjee  et  al.  relate  a  software  system’s  archi¬ 
tecture  and  its  trustworthiness  (security,  reliability,  availability, 
fault- tolerance,  and  survivability)  in  general  [10].  However, 
there  is  no  additional  detailed  guidance. 

The  notion  of  enforcing  security  requirements  at  the  archi¬ 
tectural  level  is  attractive  because  it  allows  security  concerns 
to  be  recognized  early  in  the  development  process  and  can 
be  given  sufficient  attention  in  subsequent  stages.  By  control¬ 
ling  system  security  during  architectural  refinement,  we  can 
decrease  software  production  costs  and  speed  up  the  time  to 
market.  This  approach  also  enhances  the  role  of  the  software 
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architects  by  requiring  that  their  decisions  be  not  only  for 
functional  decomposition,  but  also  for  NER  fulfillment.  In  this 
paper,  we  present  a  set  of  architectural  refinement  patterns  for 
system  design  architects  to  follow  to  achieve  secure  system 
architectures. 

As  some  researchers  have  pointed  out  [2],  [3],  [5],  effective 
refinement  must  be  technology-  and  domain-specific.  Also, 
Garlan  [11]  points  out  that  refinement  patterns  must  be  explicit 
about  what  kinds  of  properties  they  are  preserving  in  the 
refined  design.  In  this  paper,  the  type  of  systems  within 
which  our  design  refinement  patterns  are  valid  is  a  multi¬ 
level  secure  (MLS)  system.  We  focus  specifically  on  achieving 
confidentiality,  not  availability  or  integrity,  for  secure  systems. 

This  paper  is  organized  as  follows:  Section  II  introduces 
MLS  systems  and  the  concept  of  architecture;  Section  III 
proposes  architectural  refinement  patterns  that  can  be  applied 
to  MLS  systems  design.  Section  IV  presents  an  example  of 
MLS  system  design  to  illustrate  the  refinement  patterns  we 
proposed.  Einally,  we  provide  a  discussion  in  Section  V  and 
conclusion  and  future  work  in  Section  VI. 

II.  Background 
A.  MILS,  MLS,  MSLS  and  SLS 

Traditionally,  the  military  model  of  a  secure  system  includes 
the  concept  of  multi-level  security  (MLS).  The  idea  behind 
this  concept  is  that  the  system  will  be  processing  data  items 
that  are  classified  at  different  levels  of  security,  and  the 
security  requirements  that  prevent  the  transfer  of  high-level 
classified  information  into  low-level  objects  must  be  preserved. 
Therefore,  we  define  an  MLS  system  as  one  that  must  be 
certified  to  process  and  output  co-mingled  data  at  multiple 
classification  levels.  Classic  security  models,  such  as  the  Bell- 
LaPadula  (BLP)  model  [12],  have  been  used  to  specify  the 
secure  behavior  of  such  MLS  systems.  Given  a  set  of  subjects, 
each  with  a  clearance  level,  and  a  set  of  objects,  each  with  a 
classification  level,  the  BLP  model  requires  that  information 
does  not  flow  downward  by  imposing  the  following  require¬ 
ments. 

The  Simple  Security  Property.  A  subject  is  allowed  a  read 
access  to  an  object  only  if  the  subject’s  clearance  level  is 
identical  to  or  higher  than  the  object’s  classification  level. 

The  *-Property.  A  subject  is  allowed  a  write  access  to  an 
object  only  if  the  subject’s  clearance  level  is  identical  to  or 
lower  than  the  object’s  classification  level. 
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In  this  paper,  we  use  security  level  to  represent  both  the 
classification  level  and  the  clearance  level. 

The  problem  with  full  MLS  systems  is  that  they  must  be 
rigorously  analyzed  for  security  before  they  can  be  certified. 
Every  portion  of  the  MLS  system  must  be  analyzed  to  ensure 
that  it  properly  handles  labelled  data  and  that  there  is  no 
possible  violation  of  the  security  requirements.  Even  with 
a  trusted  computing  base  (TCB)  architecture  or  reference 
monitor  [13],  there  is  often  too  much  to  evaluate. 

The  Multiple  Independent  Levels  of  Security/Safety  (MILS) 
architecture  was  developed  to  resolve  the  difficulty  of  cer¬ 
tification  of  MLS  systems  by  separating  out  the  security 
mechanisms  and  concerns  into  manageable  components  [14]. 
These  components  are  classified  based  on  the  way  they  process 
data: 

•  SLS  Single-Level  Secure  component  that  only  processes 
data  at  one  security  level. 

•  MSLS  Multiple  Single-Level  Secure  component  that 
processes  data  at  multiple  security  levels  but  always 
maintains  separation  between  classes  of  data.  An  MSLS 
process  or  device  separates  the  data  into  independent 
streams  with  no  communication  between  streams.  A 
device  that  processes  messages  one  at  a  time  (such  as 
an  EO  device  driver)  may  be  such  a  device. 

•  MLS  Multi-Level  Secure  component  that  deals  with  data 
at  multiple  security  levels  and  transforms  the  data  from 
one  level  to  another  according  to  internal  MLS  security 
requirements  of  this  component.  Because  of  the  potential 
seriousness  of  violating  its  security  requirements,  an  MLS 
component  requires  the  highest  level  of  scrutiny  and 
verification.  Typically  this  can  be  a  device  that  will 
downgrade  information  from  a  higher  level  of  security 
to  a  lower  level  through  either  filtering  or  the  application 
of  encryption  technology. 

A  MILS  system  isolates  processes  into  partitions,  which 
define  a  collection  of  data  objects,  code  and  system  resources. 
These  individual  partitions  can  be  evaluated  separately,  if  the 
MILS  architecture  is  implemented  correctly.  This  divide-and- 
conquer  approach  will  exponentially  reduce  the  proof  effort  for 
secure  systems.  The  MILS  architecture  is  MLS  if  it  enforces 
the  MLS  security  requirements  to  regulate  the  communica¬ 
tion  between  the  applications  and  the  resources,  which  is 
application-specific  and  not  part  of  the  MILS  architecture. 

B.  Software  Architecture 

In  the  literature,  a  software  architecture  is  usually  described 
by  components,  connectors,  and  architectural  configurations 
[15].  The  following  concepts  are  derived  from  Medvidovic 
and  Taylor  [15]. 

A  component  in  an  architecture  is  a  unit  of  computation  or 
a  data  store.  They  may  be  as  small  as  a  single  procedure  or  as 
large  as  an  entire  application.  Each  component  may  require  its 
own  data  or  execution  space,  or  it  may  share  them  with  other 
components.  The  features  of  a  component  include  interfaces, 
semantics,  constraints,  NERs,  etc. 


Connectors  are  architectural  building  blocks  used  to  model 
interactions  between  components  and  rules  that  govern  those 
interactions.  They  may  be  message  routing  devices,  shared 
variables,  buffers,  dynamic  data  structures,  client-server  proto¬ 
cols,  pipes,  SQL  links  between  a  database  and  an  application, 
and  so  on.  Connectors  are  characterized  by  their  interfaces, 
semantics,  constraints,  NERs,  etc. 

A  component’s  interface  is  a  set  of  interaction  points 
between  it  and  the  external  world.  It  specifies  the  services 
(messages,  operations,  and  variables)  a  component  provides 
to  or  that  are  required  of  other  components  in  an  architecture. 
In  our  approach,  we  augment  the  interface  with  security  levels 
for  each  service. 

A  connector’s  interface  is  a  set  of  interaction  points  be¬ 
tween  the  connector  and  the  components  and  other  connectors 
attached  to  it.  A  connector  does  not  perform  any  application- 
specific  computations,  and  it  exports  as  its  interface  those 
services  it  expects  of  its  attached  components.  In  our  approach, 
we  also  augment  the  interface  with  security  levels  for  each 
service. 

Architectural  configurations  are  connected  graphs  of  com¬ 
ponents  and  connectors  that  describe  architectural  structure. 
In  this  paper,  we  represent  architectures  as  directed  graphs. 
The  graphs  are  integral  to  our  refinement  method,  as  they  are 
used  to  represent  the  architectures  throughout  the  refinement 
process  and  to  specify  pre-  and  post-conditions  on  each 
refinement  step. 

III.  Refinement  Patterns 

When  designing  secure  systems,  we  do  not  want  to  sepa¬ 
rately  construct  abstract  and  concrete  architectures  and  then 
prove  that  the  concrete  architecture  satisfies  the  security  prop¬ 
erties  of  the  abstract  one.  Instead,  the  concrete  architecture 
should  satisfy  the  security  properties  by  construction,  requiring 
no  explicit  proofs  in  its  derivation.  This  can  be  accomplished 
through  a  series  of  small,  local  refinements,  each  of  which 
involves  the  application  of  a  secure  refinement  pattern.  Then, 
the  local  refinements  are  combined  to  form  the  larger  com¬ 
posite  concrete  architecture,  which  is  guaranteed  to  correctly 
implement  the  abstract  architecture,  meaning  that  the  security 
properties  are  not  violated  by  the  concrete  architecture.  In  this 
way,  the  architecture  can  be  refined  to  be  more  and  more 
concrete  until  the  implementation  architecture  is  achieved. 

In  our  paper,  we  do  not  focus  on  how  to  do  functional 
requirements  (ER)  refinement,  which  has  already  been  re¬ 
searched  for  many  years  with  many  approaches  described  in 
the  literature  (e.g.,  [16]  and  [17]).  Instead,  we  focus  on  how 
to  augment  architectural  refinement  with  security  concerns. 
We  present  and  justify  informally  a  set  of  refinement  pat¬ 
terns  for  refining  components,  connectors,  and  interfaces.  The 
proposed  patterns  allow  architects  to  decompose,  aggregate, 
and  eliminate  components,  connectors,  and  ports  securely.  In 
Section  IV  we  apply  these  patterns  to  a  simple  example  for 
illustration.  Each  refinement  pattern  is  represented  by  a  pair 
of  directed  graphs  representing  the  pre-  and  post-condition  of 
the  refinement.  In  the  graphs,  a  box  represents  a  component. 


an  arrow  represents  a  connector,  and  a  dot  represents  a  port.  In 
the  rest  of  this  paper,  we  use  ports  to  represent  the  interaction 
points  of  an  interface. 

A  component/connector  is  said  to  be  trusted  if  it  is  or  will  be 
designed  to  satisfy  security  requirements,  while  an  untrusted 
component/connector  has  no  security  requirements.  The  secu¬ 
rity  requirements  associated  with  components/connectors  de¬ 
scribe  not  what  they  should  do  (e.g.,  send  some  data),  but  how 
they  should  do  it  (e.g.,  send  data  embedded  in  legal  CORBA 
messages  and  with  correct  security  labels).  In  our  work  we 
explicitly  define  two  types  of  security  requirements,  intra¬ 
level  requirements  and  inter- level  requirements.  Intra-level 
requirements  are  security  requirements  that  are  not  related  to 
information  flow  between  security  levels.  For  example,  “Mes¬ 
sages  from  Database  must  be  CORBA  reply  messages”  is  such 
an  intra-level  requirement.  This  requirement  is  not  on  cross¬ 
level  information  flow,  but  on  message  types.  Inter-level  re¬ 
quirements  are  security  requirements  that  are  related  to  cross¬ 
level  information  flows.  For  example,  “A  top-secret  message 
cannot  flow  to  a  secret  component  unless  it  is  downgraded” 
is  such  an  inter-level  requirement.  An  SLS  component  only 
has  intra-level  requirements.  An  MSLS  component,  however, 
has  not  only  intra-level  requirements  for  each  security  level, 
it  must  also  have  an  MSLS  inter-level  requirement  that  there 
is  no  cross-level  information  flow.  An  MLS  component  may 
have  intra-level  requirements  for  each  security  level  and  will 
have  some  MLS  inter-level  requirements  to  regulate  cross¬ 
level  information  flow.  In  the  final  concrete  architecture,  if 
a  connector  has  some  security  requirements,  they  must  be 
application-independent. 

Definition  1.  (Secure  Refinement)  We  say  that  a  refinement 
on  a  part  of  the  architecture  (on  components,  connectors,  ports, 
or  a  combination  of  these  entities)  is  secure  if  and  only  if  the 
new  security  requirements  on  this  part  after  the  refinement  do 
not  violate  the  original  security  requirements. 

The  refinement  may  add  some  new  requirements,  either 
functional  or  security  requirements,  but  the  new  added  require¬ 
ments  should  not  violate  the  original  security  requirements. 
This  means  that  the  security  requirements  after  the  refinement 
should  be  as  strict  as  or  stricter  than  those  before  the  refine¬ 
ment. 

In  the  following  subsections,  we  present  a  basic  set  of  refine¬ 
ment  patterns  for  decomposition,  aggregation,  and  elimination 
of  components,  connectors,  and  ports.  We  informally  justify 
that  these  refinement  patterns  are  secure  if  the  pre-  and  post¬ 
conditions  of  the  refinements  are  satisfied. 

A.  Decomposition  Patterns 

In  the  refinement  process,  it  is  typical  to  divide  an  ar¬ 
chitectural  entity  into  smaller  parts  through  decomposition. 
Decomposition  can  be  applied  to  components,  connectors,  and 
ports. 

1 )  Component  Decomposition  Patterns:  A  component  can 
be  decomposed  into  two  components  that  are  composed 
through  product,  cascade,  or  feedback  [18],  [19].  These  three 
types  of  component  decomposition  are  depicted  in  Figs.  1,  2, 


Fig.  1.  Component  Decomposition  Product  Pattern 


and  4,  respectively.  Depending  on  the  security  requirements 
of  the  initial  component,  Cmi,  there  are  different  possible 
requirements  of  the  subcomponents,  Cmn  and  Cmi2.  We 
discuss  these  in  detail  in  this  section  and  summarize  them  in 
Table  1.  Specifically,  in  Table  I  we  list  the  initial  component 
type  (SLS,  MSLS  or  MLS)  as  a  pre-condition  and  then 
the  possible  refinements  to  subcomponent  types  as  a  post¬ 
condition,  based  on  three  different  architectural  decomposition 
approaches. 

In  addition  to  the  post-conditions  listed  in  Table  I,  there  is  an 
additional  post-condition  for  all  refinement  patterns:  services 
and  security  levels  associated  with  each  port  connected  to  the 
environment  are  the  same  before  and  after  the  refinement.  We 
will  not  repeat  this  condition  when  we  elaborate  pre-conditions 
and  post-conditions  of  each  secure  refinement  pattern. 

Product  Pattern.  The  first  component  decomposition  pat¬ 
tern  we  discuss  is  Product  (Fig.  1).  In  this  pattern,  Cmi  is 
constructed  by  the  parallel  composition  of  Cmu  and  Cmi2. 

Product  Condition  1  (SLS):  If  component  Cmi  is  an  SLS 
component,  it  can  be  securely  refined  into  a  product  of  Cmu 
and  Cmi2  when  both  Cmu  and  Cmi2  are  SLS  components 
and  where  Cmu  and  Cmi2  together  enforce  the  intra-level 
requirements  of  Cmi. 

Product  Condition  2  (MSLS):  If  component  Cmi  is  an 
MSLS  component,  there  are  three  different  secure  refinements 
into  the  two  SLS  components,  Cmu  and  Cmi2. 

1)  The  refinement  is  secure  when  Cmu  and  Cmu  are  both 
SLS  components  and  each  component  enforces  intra¬ 
level  requirements  for  one  security  level,  where  Cmi 
is  an  MSLS  component  with  just  two  different  security 
levels. 

2)  The  refinement  is  secure  when  one  of  the  components 
(e.g.,  Cmu)  is  an  SLS  component  while  another  (e.g., 
Cmu)  is  an  MSLS  component.  In  this  case,  usually 
Cmi  is  an  MSLS  component  with  more  than  two 
different  security  levels,  Cmu  enforces  intra-level  re¬ 
quirements  for  one  security  level,  and  Cmu  enforces 
not  only  intra-level  requirements  for  other  security  levels 
but  also  the  inter-level  requirement  that  there  is  no  cross¬ 
level  information  flow. 

3)  The  refinement  is  secure  when  both  Cmu  and  Cmu 
are  MSLS  components.  In  one  case,  Cmu  or  Cmu 
enforces  part  of  the  intra-level  security  requirements 
in  Cmi  for  all  security  levels  in  Cmi  and  enforces 


TABLE  I 

Secure  Component  Decomposition  Patterns 


Decomposition 

Approach 

Pre-condition 

Post-condition 

Cmi 

Cmu 

1  Cmi2  1 

SLS 

MSLS 

MLS 

SLS 

MSLS 

MLS 

Product 

SLS 

V 

V 

MSLS 

V 

V 

MLS 

V 

Cascade 

SLS 

V 

V* 

MSLS 

V* 

MLS 

V 

V 

V 

Feedback 

SLS 

V 

V* 

V* 

MSLS 

V* 

MLS 

V 

Extra  inter-level  requirements  added  in  these  cases 


the  inter-level  security  requirement  that  there  is  no 
cross-level  information  flow.  Otherwise  Cmu  or  Cmi2 
enforces  all  intra-level  security  requirements  in  Cmi  but 
for  only  some  of  the  security  levels  (more  than  one), 
and  enforces  an  inter-level  requirement  that  there  is  no 
cross-level  information  flow. 

Product  Condition  3:  If  component  Crrii  is  an  MLS  compo¬ 
nent,  there  are  three  secure  refinements  into  two  components, 
Cmii  and  Cmu- 

1)  The  refinement  is  secure  when  one  of  the  components 
(e.g.,  Cmu)  is  an  SLS  component  while  the  other 
(e.g.,  Cmu)  is  an  MLS  component.  In  this  case,  Cmu 
enforces  the  intra-level  requirements  for  one  security 
level,  while  Cmu  enforces  the  intra-level  requirements 
for  other  security  levels,  and  the  inter- level  requirements 
in  Cmu  do  not  violate  those  in  Cmi. 

2)  The  refinement  is  secure  when  one  of  the  components 
(e.g.,  Cmu)  is  an  MSLS  component  while  the  other 
(e.g.,  Cmu)  is  an  MLS  component.  In  this  case,  Cmu 
enforces  the  intra-level  requirements  for  more  than  one 
security  level  and  an  inter-level  requirement  to  prohibit 
cross-level  information  flow;  Cmu  enforces  the  intra¬ 
level  requirements  for  the  other  security  levels,  and  the 
inter- level  requirements  in  Cmu  do  not  violate  those  in 
Cmi. 

3)  The  refinement  is  secure  when  both  Cmu  and  Cmu 
are  MLS  components.  In  one  case,  Cmu  or  Cmu 
enforces  part  of  the  intra-level  requirements  in  Cmi 
for  all  security  levels  in  Cmi  and  enforces  inter-level 


requirements  in  Cmi.  Otherwise  both  Cmu  and  Cmu 
enforce  all  intra-level  security  requirements  in  Cmi  but 
each  for  only  some  of  the  security  levels  (more  than 
one),  and  the  inter-level  requirements  in  each  component 
do  not  violate  those  in  Cmi. 

In  all  of  the  product  decomposition  cases,  we  decompose 
the  original  component  into  two  sub-components.  The  de¬ 
composition  can  separate  our  security  concerns  by  separat¬ 
ing  the  processing  of  difference  security  levels.  When  this 
happens,  we  get  a  more  secure  system.  However,  sometimes 
the  decomposition  does  not  separate  security  levels.  In  that 
case  we  need  to  still  enforce  inter-level  security  requirements 
as  discussed  above.  In  either  case,  the  security  requirements 
of  the  subcomponents,  when  composed,  need  to  satisfy  the 
requirement  of  the  main  component. 

Cascade  Pattern.  The  second  decomposition  pattern  is 
Cascade  (Fig.  2).  In  this  pattern,  Cmi  is  constructed  through 
serial  composition  of  Cmu  ™d  Cmu- 

Cascade  Condition  1:  If  component  Cmi  is  an  SLS  com¬ 
ponent,  there  are  two  different  secure  refinements. 

1)  The  refinement  is  secure  when  both  Cmu  and  Cmu  are 
SLS  components  and  Cmu  and  Cmu  together  enforce 
the  intra-level  security  requirements  of  Cmi. 

2)  The  refinement  is  secure  when  both  Cmu  and  Cmu  are 
MLS  components.  In  this  case,  the  intra-level  require¬ 
ments  can  be  enforced  by  either  Cmu  or  Cmu  or  by 
the  two  components  together,  and  both  need  to  enforce 
additional  inter-level  requirements  that  do  not  allow 
infomration  flow  between  levels.  Such  a  refinement 


Fig.  2.  Component  Decomposition  Cascade  Pattern 


Fig.  4.  Component  Decomposition  Feedback  Pattern 
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Fig.  3.  Component  Decomposition  Cascade  Pattern  Example 


could  occur  if  one  of  these  two  MLS  components  is 
an  up-grader  while  the  other  is  a  down-grader.  This 
means  that  one  component  enforces  an  inter-level  re¬ 
quirement  to  up-grade  while  the  other  enforces  an  inter¬ 
level  requirement  to  down-grade.  A  typical  example  is 
shown  in  Fig.  3.  In  this  example,  Cmi  is  an  abstract 
SLS  communication  component  that  takes  in  messages 
at  Top  Secret  (TS)  level  and  transfers  the  messages 
to  output  them  also  at  TS.  A  possible  refinement  of 
Cmi  would  involve  encrypted  communication  over  an 
insecure  channel  (connector  Cn).  We  could  have  Cmu 
be  an  encryption  device  which  takes  in  TS  messages, 
encrypts  them  with  a  key  for  TS  messages,  then  outputs 
Unclassified  (U)  messages,  and  Cmi2  be  a  decryption 
device  which  takes  in  U  messages,  decrypts  them  with 
TS  keys,  then  outputs  TS  messages.  Obviously,  Cmu 
and  Cmi2  are  both  MLS  components  and  with  their 
composition,  the  transfer  of  TS  messages  is  secure,  with 
no  message  leakage  to  lower  levels,  as  long  as  they 
support  the  new  inter-level  requirements. 

Cascade  Condition  2:  If  component  Cmi  is  an  MSLS 
component,  there  are  two  different  secure  refinements. 

1)  The  refinement  is  secure  when  both  Cmu  and  Cmi2  are 
MSLS  components.  Cmu  and  Cmu  together  enforce 
the  intra-level  security  requirements  of  Cmi,  and  each 
of  them  has  an  inter-level  requirement  to  prohibit  cross¬ 
level  information  flow. 

2)  The  refinement  is  secure  when  both  Cmu  and  Cmu 
are  MLS  components.  In  this  case,  the  intra-level  re¬ 
quirements  can  be  enforced  by  either  Cmu  or  Cmu  or 
by  the  two  components  together.  Similar  to  when  Cmi 
is  an  SLS  component,  such  a  refinement  could  occur 
if  one  of  these  two  MLS  components  is  an  up-grader 
while  the  other  is  a  down-grader.  Both  subcomponents 
must  satisfy  the  new  inter-level  requirements  that  state 
they  do  not  violate  the  original  security  requirement. 


Cascade  Condition  3:  If  component  Cmi  is  an  MLS 
component,  there  are  five  different  secure  refinements. 

1)  The  refinements  are  secure  when  CmulCmu  is  an  SLS 
component  while  CmulCmu  is  an  MLS  component. 
In  these  two  cases,  components  Cmu  and  Cmu  to¬ 
gether  enforce  the  intra-level  requirements  of  Cmi,  and 
CmulCmu  has  MLS  inter-level  requirements  which 
do  not  violate  those  of  Cmi. 

2)  The  refinements  are  secure  when  CmulCmu  is  an 
MSLS  component  and  CmulCmu  is  an  MLS  com¬ 
ponent.  In  these  two  cases,  Cmu  and  Cmu  together 
enforce  the  intra-level  requirements  of  Cmi,  and  the 
MLS  requirements  of  CmulCmu  do  not  violate  the 
MLS  inter-level  requirements  of  Cmi. 

3)  The  refinement  is  secure  when  both  Cmu  and  Cmu 
are  MLS  components.  In  this  case,  Cmu  and  Cmu 
together  enforce  the  intra-level  security  requirements  of 
Cmi,  and  the  MLS  inter-level  requirements  of  Cmu 
and  Cmu  do  not  violate  those  of  Cmi. 

Feedback  Pattern.  The  final  decomposition  pattern  is  Feed¬ 
back  (Fig.  4).  In  this  pattern,  Cmi  is  constructed  by  two 
communication  components  Cmu  and  Cmu- 

The  three  secure  refinement  cases  summarized  in  Table  I  are 
similar  to  those  for  Cascade  pattern  and  are  omitted  here  to 
save  space.  However,  it  is  important  to  note  that  some  security 
properties  are  not  preserved  under  feedback  composition  [18], 
[19],  [20].  In  Section  V,  we  discuss  feedback  composition 
further. 

2 )  Connector  and  Port  Decomposition  Patterns:  In  addition 
to  component  decomposition,  we  need  to  discuss  connector 
and  port  decomposition  as  well. 

As  discussed  in  Section  II,  in  the  final  concrete  architecture, 
a  connector  does  not  perform  any  application-specific  com¬ 
putations.  Therefore,  during  the  architectural  refinement,  for 
any  connector  with  application-specific  security  requirements 
on  it,  we  should  refine  this  connector  using  ConnDec  pattern 
(Fig.  5).  In  pattern  ConnDec,  connector  Cn  is  decomposed 
into  connectors  Cni  and  Cn2  and  component  Cm.  After  the 
ConnDec  refinement,  all  application-specific  security  require¬ 
ments  of  Cn  are  put  on  component  Cm  and  no  application- 
specific  security  requirements  are  put  on  connectors  Cni  and 
Cn2 .  Effectively,  Cm  is  a  guard  that  enforces  the  application- 
specific  security  requirements  of  Cn.  The  connectors  Cni 
and  Cn2  and  the  component  Cm  together  should  enforce  the 
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Fig.  5.  Connector  Decomposition  ConnDec  Pattern 
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Fig.  6.  Port  Decomposition  PortDecl  Pattern 


security  requirements  on  Cn. 

Two  other  post-conditions  are:  Cni.ip  has  the  same  services 
and  security  levels  as  those  of  Cn.ip  while  Cn2.op  has  the 
same  services  and  security  levels  as  those  of  Cn.op',  Cni.op 
has  the  same  security  levels  as  Cni.ip,  and  Cn2.ip  has  the 
same  security  levels  as  Cn2.op. 

When  a  connector  has  application-independent  security  re¬ 
quirements  on  it,  it  is  secure  to  refine  this  connector  into  a 
serial  composition  of  two  connectors  if  these  two  connectors 
together  enforce  the  application-independent  security  require¬ 
ments  (not  pictured  here). 

For  port  decomposition,  we  decompose  a  port  into  multiple 
ports,  splitting  the  services  and  security  levels  of  the  original 
port  to  associate  them  with  the  new  ports.  When  a  port  of 
a  component  decomposes,  nothing  changes  in  the  component 
and  no  security  requirements  will  be  violated.  For  the  connec¬ 
tor  to  this  port,  in  one  case,  such  a  port  decomposition  causes 
the  connector  to  decompose  also  (Fig.  6).  In  this  case,  we  need 
to  split  the  security  requirements  of  the  connector  Cn  to  put 
them  into  Cni  and  Cn2.  Possible  inter-level  requirements  on 
Cni  and  Cn2  should  not  violate  the  inter- level  requirements 
on  Cn. 

In  another  case,  a  port  decomposition  does  not  cause  the 
connector  to  decompose  (Fig.  7).  In  this  case,  connectors  Cni 
and  Cn2  remain  the  same,  meaning  the  security  requirements 
in  these  two  connectors  remain  the  same. 

B.  Aggregation  Patterns 

When  refining  an  architecture,  we  may  find  it  is  necessary 
to  merge  two  more  abstract  entities  into  a  single  lower  level 
entity.  Aggregation  can  be  applied  to  components,  connectors. 


Fig.  7.  Port  Decomposition  PortDec2  Pattern 


Fig.  8.  Component  Aggregation  ComAgg  Pattern 

and  ports. 

If  two  components  are  not  connected  directly,  when  we 
merge  them  as  one  component,  we  say  we  aggregate  them. 
If  two  components  are  connected  directly,  we  can  consider 
them  as  part  of  a  bigger  component,  but  not  an  aggregation. 

ComAgg  Pattern.  The  component  aggregation  pattern  we 
provide  in  this  paper  is  ComAgg  (Fig.  8).  The  six  secure 
refinement  cases  are  summarized  in  Table  11. 


TABLE  II 

Component  Aggregation  Patterns  Table 


Pre-condition 

Post-condition 

Cmi 

Cm2 

Cmi2 

SLS 

MSLS 

MLS 

SLS 

SLS 

SLS 

MSLS 

V* 

SLS 

MLS 

V* 

MSLS 

MSLS 

MSLS 

MLS 

V 

MLS 

MLS 

*  Extra 

inter-leve] 

requirements  added  in  these  cases 

ComAgg  Condition  1:  If  both  Cmi  and  Cm2  are  SLS 
components,  after  aggregation,  Cmi2  could  be  an  SLS  or 
MSLS  component.  When  Cmi  and  Cm2  have  the  same 
security  level,  Cmi2  is  an  SLS  component  that  has  the  intra¬ 
level  requirements  of  Cmi  and  Cm2',  when  Cmi  and  Cm2 
have  different  security  levels,  Cmi2  should  be  an  MSLS 
component  that  has  not  only  the  intra-level  requirements  of 
Cmi  and  Cm2,  but  also  a  new  MSLS  inter-level  requirement 
to  prohibit  cross-level  information  flow. 

ComAgg  Condition  2:  If  one  of  the  components,  Cmi  or 
Cm2,  is  an  SLS  component  and  the  other  is  an  MSLS  com¬ 
ponent,  Cmi2  is  an  MSLS  component  that  has  not  only  the 
intra-level  requirements  of  Cmi  and  Cm2,  but  also  an  MSLS 
inter-level  requirement  to  prohibit  cross-level  information  flow. 

ComAgg  Condition  3:  If  either  component  Cmi  or  Cm2 
is  an  SLS  component  (e.g.,  Cmi)  and  the  other  is  an  MLS 
component  (e.g.,  Cm2),  Cmi2  should  be  an  MLS  component 
that  has  the  intra-level  requirements  of  Cmi  and  Cm2.  The 
MLS  inter-level  requirements  of  Cmi2  should  not  violate 
those  of  Cm2. 

ComAgg  Condition  4:  If  both  Cmi  and  Cm2  are  MSLS 
components,  Cmi2  must  be  an  MSLS  component  that  en¬ 
forces  all  intra-level  requirements  of  Cmi  and  Cm2  and  has 
an  MSLS  inter-level  requirement  to  prohibit  any  cross-level 
information  flow. 

ComAgg  Condition  5:  If  either  Cmi  or  Cm2  is  an  MSLS 
component  while  the  other  is  an  MLS  component,  Cmi2 


Fig.  9.  Component  and  Connector  Aggregation  ComConnAgg  Pattern 

should  be  an  MLS  component  that  has  all  intra-level  require¬ 
ments  of  Cmi  and  Cm2-  The  MLS  inter-level  requirements 
of  Cmi2  should  not  violate  those  of  Cmi  or  Cm2.  If  there 
is  any  conflict  between  the  MLS  inter-level  requirements  and 
the  MSLS  inter-level  requirements  of  the  original  components, 
(e.g.,  in  the  MLS  inter-level  requirements,  there  is  cross¬ 
level  information  flow  between  TS  and  S,  but  in  the  MSLS 
inter-level  requirements,  there  should  not  be  any  cross-level 
information  flow)  we  require  the  stricter  requirement.  That 
means  in  Cmi2  we  follow  the  MSLS  inter-level  requirement 
instead  of  the  MLS  inter-level  requirement  when  conflict 
occurs. 

ComAgg  Condition  6:  If  both  Cmi  and  Cm2  are  MLS  com¬ 
ponents,  Cmi2  should  be  an  MLS  component  that  enforces 
all  intra-level  requirements  of  Cmi  and  Cm2,  and  the  MLS 
inter-level  requirements  of  Cmi2  should  not  violate  those  of 
Cmi  and  Cm2. 

It  is  important  to  note  that  in  ComAgg,  though  the  two 
components  do  not  interact  directly  with  each  other,  they 
both  interact  with  their  environment,  and  in  some  cases,  their 
aggregation  may  cause  a  subtle  situation  that  needs  to  be 
examined  closely,  as  will  be  discussed  in  Section  V. 

ComConnAgg  Pattern.  We  propose  an  aggregation  pattern 
ComConnAgg  (Fig.  9).  In  this  pattern,  connectors  Crii  and 
Cn2  and  component  Cm  are  aggregated  to  a  new  connector 
Cn.  This  aggregation  is  secure  if  Cn  is  trusted  to  enforce  all 
the  security  requirements  of  Cni,  Cn2,  and  Cm. 

Also,  two  connectors  composed  serially  can  be  aggregated 
to  one  connector  if  the  new  connector  does  not  violate  any 
security  requirements  of  the  two  original  connectors. 

PortAggl  and  PortAgg2  Patterns.  For  port  aggregation, 
we  aggregate  multiple  ports  into  one,  merging  the  services 
and  security  levels  of  the  original  ports  to  associate  them 
with  the  new  port.  When  the  ports  of  a  component  are 
aggregated,  nothing  changes  in  the  component  and  security 
is  not  violated.  For  the  connectors  to  these  ports,  in  one  case, 
such  a  port  aggregation  causes  the  connectors  to  aggregate  as 
well  (Fig.  10).  In  this  case,  Cni2  should  have  all  the  security 
requirements  of  Cni  and  Cn2-  Only  when  Cni2-ip,  Cni.op, 
and  Cn2-ip  have  the  same  security  level  will  there  be  no  inter¬ 
level  requirements  on  Cni2',  otherwise,  there  should  be  inter¬ 
level  requirements  on  C'ni2,  and  these  should  not  violate  the 
inter-level  requirements  of  Crii  and  Cn2- 

In  another  case,  ports  aggregation  does  not  cause  connectors 
with  these  ports  to  aggregate  (Fig.  1 1).  In  this  case,  after  the 
port  aggregation,  connectors  Cni  and  Cn2  remain  the  same, 
meaning  all  security  requirements  of  these  two  connectors 
remain  the  same. 


Fig.  10.  Port  Aggregation  PortAggl  Pattern 


Fig.  11.  Port  Aggregation  PortAgg2  Pattern 


C.  Elimination  Patterns 

Simply  stated,  for  any  connector  with  no  semantics,  mean¬ 
ing  no  functionality  is  provided  by  it,  we  can  securely  elim¬ 
inate  this  connector.  Elimination  of  a  component  is  secure  if 
the  component  has  no  connection  to  other  components.  Also, 
elimination  of  a  port  is  secure  if  it  has  no  connection  to  its 
environment. 

IV.  A  MILS  Application  Design  Example 

In  this  section,  we  present  an  example  of  a  MILS  application 
system  to  illustrate  how  to  refine  a  system  design  according  to 
the  refinement  patterns  described  in  the  previous  section.  The 
system  is  simple  enough  to  avoid  complexity  for  the  purposes 
of  discussion  but  sufficient  to  illustrate  the  concepts  discussed. 
The  specifications  for  the  system  are:  A  distributed,  MLS 
secure  (suppose  there  are  two  security  levels  used,  TS  and 
S),  MILS  application  system  that  allows  users  with  different 
security  levels  to  store  and  retrieve  data  on  an  MLS  database 
using  legal  CORBA  messages  (i.e.,  legal  means  read,  write 
methods  for  users  and  reply  method  for  database).  Assume 
user  Ui  is  at  TS  level  while  user  U2  is  at  S  level  and  the 
database  DB  is  remotely  accessible  by  both  Ui  and  U2- 
The  functional  requirements  of  this  application  are:  store  and 
retrieve  data.  The  security  requirements  are:  1.  inter-level 
requirements:  store/retrieve  data  obeying  BLP  model;  2.  intra¬ 
level  requirements:  all  messages  sent  should  be  legal  CORBA 
messages. 

The  abstract  architecture  of  this  system  is  depicted  in  Eig. 

12. 

In  the  abstract  architecture,  connector  Cuu^-db  has  the  ER 
that  it  forwards  messages  from  Ui  to  DB,  located  at  different 
computers.  The  security  level  associated  with  the  ports  of 


Fig.  12.  The  Abstract  Architecture  of  the  Application  Example 


Fig.  13.  An  Architecture  of  the  Example  after  Step  1:  ConnDec 


Fig.  14.  An  Architecture  after  Step  2:  ComAgg 


this  connector  is  TS.  The  security  requirements  of  Cuu^-db 
are  listed  in  Table  III,  No.  1  and  2.  Connectors  Cnu2-DB, 
Cudb-Ui,  CnDB-U2  have  similar  functionality  and 
security  requirements. 

We  now  illustrate  several  refinement  steps  of  the  application 
system  design  to  obtain  a  secure  concrete  system  architecture. 

Step  1.  The  abstract  architecture  can  be  first  refined  by 
applying  the  connector  decomposition  pattern  ConnDec  to 
the  connector  Cnjji-DB-  The  original  connector  is  decom¬ 
posed  into  connector  Cnjji-Xi,  component  Xi,  and  connec¬ 
tor  Cnxi-DB  (Fig-  13).  According  to  the  post-conditions 
of  pattern  ConnDec,  we  place  application-specific  security 
requirements  on  component  Xi  and  make  the  connectors 
Cnui-Xi  and  Cuxi-db  application-independent.  After  the 
refinement,  Cnui-Xi  has  the  FR  that  it  forwards  messages 
between  different  partitions  in  MILS  architecture,  and  the 
NFR  that  the  security  level  associated  with  the  ports  of  this 
connector  remains  TS.  The  FR  of  connector  Cux^-db  is  the 
same  as  that  of  Cnjji-Xi,  and  the  security  level  associated 
with  the  ports  of  this  connector  remains  TS.  Component  Xi 
has  the  security  requirements  in  Table  III,  No.  7  and  8. 
Also,  Xi  has  the  functionality  to  forward  messages  between 
different  computers.  Similarly,  the  decomposition  pattern  Con¬ 
nDec  is  applied  to  the  connectors  Cnu2-DB,  CnoB-ih,  and 
CnDB-U2^  and  the  new  architecture  is  achieved  (Fig.  13). 

Here,  we  can  say  that  this  is  a  big-step  refinement  which 
includes  multiple  mini-steps.  A  mini-step  refinement  applies 
one  refinement  pattern  to  a  component,  connector,  or  inter¬ 
face,  while  a  big-step  is  a  set  of  mini-steps  applied  to  the 
architecture  refinement  sequentially. 

Step  2.  We  take  the  architectural  refinement  further  by 
applying  component  aggregation  pattern  ComAgg  to  the  ar¬ 
chitecture  of  Fig.  13,  resulting  in  the  architecture  in  Fig.  14. 

In  this  step  of  refinement,  the  component  aggregation  pat¬ 
tern  ComAgg  is  applied  to  Xi  and  X^.  After  the  refinement, 
the  security  requirements  of  component  Xi^,  No.  13  and  14  in 
Table  III,  do  not  violate  the  security  requirements  of  ATi  and 
X^.  Also,  2fi3  has  the  FR  of  forwarding  messages  between 
different  computers.  Similarly,  the  component  aggregation 
pattern  ComAgg  is  applied  to  X2  and  X^  to  get  a  component 
2^24.  The  services  and  security  levels  of  all  ports  remain  the 
same  as  those  in  Fig.  13. 

Step  3.  Further,  we  apply  ComAgg  pattern  to  the  previous 
architecture  to  aggregate  components  X13  and  X24,  and  the 


Fig.  15.  An  Architecture  after  Step  3:  ComAgg 


Fig.  16.  Part  of  Architecture  after  Step  4:  Feedback 

new  architecture  is  in  Fig.  15. 

After  the  refinement,  component  X  has  the  security  require¬ 
ments  No.  17  and  18  in  Table  III  which  do  not  violate  the 
security  requirements  of  Xi^  and  2^24.  Also,  component  X  has 
the  FR  of  forwarding  messages  between  different  computers. 
Services  and  security  levels  associated  with  all  ports  remain 
the  same  as  those  in  Fig.  14. 

Step  4.  Now,  we  apply  component  decomposition  pattern 
Feedback  to  decompose  component  2f  to  a  feedback  compo¬ 
sition  of  X'  and  X'  shown  in  Fig.  16. 

In  this  step  of  refinement,  component  X'  has  the  security 
requirements  No.  19  and  20  in  Table  III,  which  also  do  not 
violate  the  security  requirements  of  2f.  2f'  has  new  MLS  inter¬ 
level  requirements.  No.  21,  to  downgrade  TS/S  messages  to  U 
messages  by  encrypting  them  with  a  TS/S  key  before  forward¬ 
ing,  and  to  upgrade  U  messages  to  TS/S  by  decrypting  them 
with  a  TS/S  key  before  forwarding.  These  new  MLS  inter¬ 
level  requirements  do  not  violate  the  security  requirements  of 
X.  Connectors  Cnx'-x'  transfer  messages  between  different 
computers.  These  connectors  are  application-independent.  The 
security  level  associated  with  the  ports  of  these  connectors  is 
U. 

Step  5.  We  continue  refining  component  X'  in  Fig.  16 
by  applying  component  decomposition  pattern  Feedback  to 
decompose  X'  into  a  feedback  composition  of  X”  and  a 
component  named  TNIU  as  shown  in  Fig.  17.  The  component 
TNIU  has  the  MLS  inter-level  requirements.  No.  24  in  Table 
III,  to  downgrade/upgrade  all  messages  it  receives  before  for¬ 
warding  them.  Component  X”  has  the  security  requirements 
No.  22  and  23  in  Table  III,  which  do  not  violate  the  security 
requirements  No.  19  and  20  of  X' .  Connectors  Cnx"-TNiu 
and  CriTNiu-X"  can  transfer  messages  using  direct  process 
calls. 

Step  6.  Now,  the  component  26"  in  Fig.  17  can  be  de¬ 
composed  into  components  MMR  and  GG  by  applying 
component  decomposition  pattern  Feedback  as  shown  in  Fig. 


Fig.  17.  Part  of  the  Architecture  after  Step  5:  Feedback 


TABLE  III 

Application  Requirements  Enforcement  Table 


Com/Conn 

No. 

Intra-level  Requirements 

Inter-level  Requirements 

Cnui-DB 

1 

Messages  are  legal  CORBA  messages. 

2 

TS  level,  read  and  write  according  to  BLR 

Cnu^_]jB 

3 

Messages  are  legal  CORBA  messages. 

4 

S  level,  read  and  write  according  to  BLR 

CnoB-u^ 

5 

Messages  are  legal  CORBA  messages. 

CnoB-u-? 

6 

Messages  are  legal  CORBA  messages. 

Xi 

7 

Messages  are  legal  CORBA  messages. 

8 

Ui  read/write  TS  messages  and  read  S  messages. 

^2 

9 

Messages  are  legal  CORBA  messages. 

10 

U2  read/write  S  messages  and  write  TS  messages. 

^3 

11 

Messages  are  legal  CORBA  messages. 

X4 

12 

Messages  are  legal  CORBA  messages. 

^13 

13 

Messages  from  Ui  to  DB  are  legal  CORBA  mes¬ 
sages;  messages  from  DB  to  Ui  are  legal  CORBA 
messages. 

14 

Ui  read/write  TS  data  and  read  S  data. 

X2i 

15 

Messages  from  U2  to  DB  are  legal  CORBA  mes¬ 
sages;  messages  from  DB  to  U2  are  legal  CORBA 
messages. 

16 

U2  read/write  S  data  and  write  TS  data. 

X 

17 

Messages  from  U\  and  U2  to  DB  are  legal  CORBA 
messages;  messages  from  DB  to  Ui  and  U2  are 
legal  CORBA  messages. 

18 

Ui  read/write  TS  data  and  read  S  data;  U2  read/write  S  data 
and  write  TS  data. 

19 

Messages  from  U\  and  U2  to  DB  are  legal  CORBA 
messages;  messages  from  DB  to  Ui  and  U2  are 
legal  CORBA  messages. 

20 

Ui  read/write  TS  data  and  read  S  data;  U2  read/write  S  data 
and  write  TS  data. 

21 

Downgrading  TS/S  messages  to  U  by  encrypting  with  TS/S 
key;  upgrading  U  messages  to  TS/S  by  decrypting  with  TS/S 
key. 

X" 

22 

Messages  from  U\  and  U2  to  DB  are  legal  CORBA 
messages;  messages  from  DB  to  Ui  and  U2  are 
legal  CORBA  messages. 

23 

Ui  read/write  TS  data  and  read  S  data;  U2  read/write  S  data 
and  write  TS  data. 

TNIU 

24 

Downgrading  TS/S  messages  to  U  by  encrypting  with  TS/S 
key;  upgrading  U  messages  to  TS/S  by  decrypting  with  TS/S 
key. 

MMR 

25 

Forwarding  different  types  of  messages  to  the  correct 
type  checking  components. 

26 

Messages  from  different  partitions  must  be  labelled  correctly 
with  security  levels  of  the  partitions. 

GG 

27 

All  messages  received  must  be  checked  to  be  legal 
CORBA  messages. 

28 

Ui  read/write  TS  data  and  read  S  data;  U2  read/write  S  data 
and  write  TS  data. 

DB 

29 

Reply  with  legal  CORBA  messages. 

30 

Reply  to  requests  with  data  at  proper  classification  levels. 

Eig.  18.  Part  of  the  Architecture  after  Step  6:  Eeedback 


18. 

In  this  step  of  refinement,  the  component  MMR  enforces 
the  intra-level  requirement  No.  25  and  the  MSLS  inter¬ 


level  requirement  No.  26  in  Table  III.  The  component  GG, 
representing  a  GIOP  Guard,  enforces  security  requirements 
No.  27  and  28  in  Table  III.  Connectors  Gumaix-gg 
CnoG-MMX  can  transfer  messages  using  direct  process  calls, 
and  the  security  levels  associated  with  the  ports  of  this 
connector  are  TS  and  S. 

After  all  these  steps,  we  take  one  additional  refinement  step 
by  applying  port  aggregation  patterns  PortAgg2  and  PortAggl 
sequentially  to  aggregate  the  ports  and  connectors  between  the 
MMR  and  DB  to  get  the  final  concrete  architecture  shown 
in  Fig.  19.  The  security  levels  associated  with  the  ports  of  the 
connectors  between  MMR  and  DB  are  TS  and  S. 


Fig.  19.  Final  Concrete  Architecture  of  the  Application  Example 
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Fig.  20.  Trace  of  Security  Requirements  Enforcement 


Through  the  justification  of  each  step  of  refinement,  we  can 
informally  guarantee  that  this  concrete  architecture  is  a  secure 
design  of  the  application  example,  if  components  MMR, 
GG,  TNIU,  and  DB  are  trusted  to  enforce  all  security 
requirements  put  on  them  during  the  refinement  as  in  Table 
III. 

The  trace  of  how  the  original  security  requirements  are 
enforced  during  the  refinement  process  is  presented  in  Fig. 
20.  The  numbers  in  the  figure  represent  the  respective  security 
requirements  in  Table  III. 

By  walking  through  the  design  of  this  application  example, 
we  can  see  that  our  refinement  patterns  can  be  guidance  for 
architects  to  apply  them  to  each  step  of  architecture  design 
refinement  and  to  justify  each  mini-step  to  reach  a  concrete 
architecture  with  no  need  for  additional  proofs. 

V.  Discussion 

In  this  paper,  when  we  design  a  secure  MLS  system, 
we  enforce  intra-level  requirements  and  prohibit  any  direct 
information  flow  that  is  not  permitted  by  the  inter-level  re¬ 
quirements,  but  we  do  not  address  indirect  information  flow.  If 
a  system  needs  to  achieve  a  stringent  security  property,  such  as 
generalized  non-interference  (GNI)  [20],  [18],  [19],  feedback 
composition  of  two  components  must  be  examined  closely.  As 
pointed  out  in  the  literature,  in  some  cases,  the  direct  feedback 
composition  of  two  secure  components  could  be  insecure  in 
terms  of  GNI. 

In  the  refinement  patterns  we  presented,  the  direct  feedback 


Fig.  21.  Feedback  Composition  of  Two  Components  after  Aggregation 


Fig.  22.  Possible  Insecure  Component  Aggregation  Example 

composition  of  two  components  occurs  in  the  component 
decomposition  pattern  Feedback.  Alternatively,  the  feedback 
composition  of  two  components  could  occur  after  applying  the 
component  aggregation  ComAgg  (Fig.  21),  where  components 
Gmi  and  Gm^.  aggregate  to  a  component  Grnis  and  Grnis 
is  feedback  composed  with  Gm2  after  the  refinement. 

In  some  cases,  a  feedback  composition  is  secure  before 
refinement,  but  after  refinement,  the  composition  could  be 
insecure  (Fig.  22).  In  this  component  aggregation,  the  direct 
feedback  composition  of  Gmi  and  Gm2  is  secure  before  the 
aggregation;  however,  if  Gmi  and  Cm3  deal  with  different 
security  levels,  the  direct  feedback  composition  of  Cmia 
and  Cm2  could  be  insecure  when  these  two  components  are 
aggregated. 

No  matter  what  causes  the  feedback  composition  of  two 
non-SLS  components,  the  architect  should  not  only  put  MSLS 
requirements  or  MLS  requirements  on  the  components,  but 
also  refer  to  secure  composition  approaches  [20],  [19]  to  check 
and  eliminate  any  unpermitted  indirect  cross-level  information 
flow.  For  example,  one  approach  is  to  add  a  buffer  in  the 
feedback  connection  between  these  two  components.  Only 
when  Cmi  and  Cm2  are  both  SLS  components  and  at  the 
same  security  level  do  architects  not  need  to  consider  this 
subtle  situation. 

In  component  decomposition  pattern  Cascade,  when  Cmi 
is  an  MSLS  component,  either  Cmu  or  Cmi2  could  be  an 
MSLS  component  while  the  other  is  an  SLS  component  (Fig. 
23).  However,  we  do  not  list  these  post-conditions  in  Table 
I  since  such  a  decomposition  can  be  achieved  by  applying 
a  set  of  refinement  patterns  sequentially  (Fig.  24).  We  can 
consider  Cascade(MSLS^SLSH-MSLS)  as  a  pattern  of  big- 


Fig.  23.  A  Cascade  Pattern  (MSLS— >SLS+MSLS) 
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Fig.  24.  Applying  a  Set  of  Mini-step  Refinements 


step  refinement  which  can  be  achieved  through  applying  a  set 
of  mini-steps. 

For  component  decomposition  pattern  Feedback,  when 
Crrii  is  an  MSLS  component,  either  Cmu  or  Cmi2  could  be 
an  MSLS  component  while  the  other  is  an  SLS  component.  We 
do  not  list  these  post-conditions  in  Table  I  for  similar  reason 
as  for  pattern  Cascade. 

VI.  Conclusions  and  Future  Work 

In  this  paper,  we  present  a  set  of  refinement  patterns 
for  components,  connectors,  and  interfaces  in  architectures. 
With  informal  justification  of  these  patterns,  we  provide  a 
framework  for  secure  system  architecture  design. 

In  subsequent  work,  we  will  formally  verify  that  these 
refinement  patterns  are  secure  by  mathematically  modelling 
these  patterns  and  providing  mathematics  theorems  as  criteria 
for  secure  refinement. 

We  will  work  on  deciding  a  necessary  and  sufficient  set  of 
basic  refinement  patterns  on  which  other  refinement  patterns 
can  be  built.  For  example,  the  Cascade(SLS^SLSH-SLS)  is 
such  a  pattern,  but  Cascade(MSLS^SLSH-MSLS)  discussed  in 
Section  V  is  not.  We  call  this  set  the  Core  set,  or  Level-0  set. 
New  patterns  can  be  built  on  patterns  in  Level-0,  and  a  Level- 
1  set  consists  of  the  new  patterns.  Intuitively,  the  architects 
can  build  their  own  patterns  in  any  Level-n  set  based  on  the 
patterns  in  Level-0  to  Level-(n-l)  sets.  The  verification  of 
patterns  in  Level-n  can  build  on  the  verification  of  patterns 
in  lower  level  sets,  which  can  reduce  the  verification  efforts. 

Finally,  we  will  work  on  formalizing  the  secure  architectural 
refinement  framework  by  using  Unified  Modeling  Language 
(UML).  Since  UML  is  used  during  software  development  from 
early  phases  to  detailed  design,  performing  and  presenting 
the  architectural  refinements  of  secure  systems  in  UML  will 
make  them  comprehensible  to  everyone  involved.  With  a  for¬ 
mal  framework  of  secure  architectural  refinements  in  system 
design,  we  can  perform  solid  components  interaction  analysis 
and  verify  that  their  composition  results  in  desired  behavior 
and  security  properties. 
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